ptkbfandomcom-20200213-history
Bluetooth
Bluetooth is a low cost, low power, short-range radio technology intended to replace cable connections between cellphones, PDAs and other portable devices. It can clean up your desk considerably, making wires between your workstation, mouse, laptop computer etc. obsolete. Overview Bluetooth is a networking protocol stack following the OSI model. The layers from "Link Manager" and below are usually implemented in hardware, while the layers above it are usually implemented in software. Application developers do not need to know all the details about the layers in the Bluetooth stack. Definitions and Assumptions Blutooth Networks A piconet is the usual form of a Bluetooth network and is made up of one master and one or more slaves. The device initiating a Bluetooth connection automatically becomes the master. A piconet can consist of one master and up to seven active slaves. The master device is literally the master of the piconet. Slaves may only transmit data when transmission-time is granted by the master device, also slaves may not communicate directly with each other, all communication must be directed through the master. When connecting two piconets the result will be a scatternet. Bluetooth links Two types of physical links are defined in version 1.1 of the Bluetooth specification, Synchronous Connection Oriented (SCO) links and Asynchronous ConnectionLess (ACL) links. The SCO and ACL links are part of the baseband specification. SCO links are intended for audio transmission. ACL links are intended for data communication. An ACL link provides error-free transmission of data which means that lost or erronous packets are re-transmitted. The maximum data rate at the application level is around 650 kbps for an ACL link. Only one ACL link can exist between two devices. L2CAP and RFCOMM are separate layers in the Bluetooth stack which rely on an ACL physical link for data transmission. L2CAP L2CAP provides multiplexing between different higher layer protocols over a single physical ACL link, enabling several logical data links to be set up between two Bluetooth devices. L2CAP also provides segmentation and reassembly of packets from higher layers. Different protocols use different packet sizes, some of these may need to be segmented in order to be sent over an ACL link due to package size constraints. An ACL packet can have a maximum of 339 bytes of payload data, while an L2CAP packet can have a maximum of 65,535 bytes of payload data. RFCOM The RFCOMM layer emulates RS-232 serial ports and serial data streams. RFCOMM relies on L2CAP for multiplexing multiple concurrent data streams and handling connections to multiple devices. The majority of Bluetooth profiles make use of the RFCOMM protocol because of its ease of use compared to direct interaction with the L2CAP layer. Discovery Device Discovery The Bluetooth Specification refers to the device discovery operation as inquiry. During the inquiry process the inquiring Bluetooth device will receive the Bluetooth address and clock from nearby discoverable devices. Also, discoverable devices make use of an Inquiry Access Code (IAC). Two IACs exist, the General Inquiry Access Code (GIAC) and the Limited Inquiry Access Code (LIAC). The GIAC is used when a device is general discoverable, meaning it will be discoverable for a undefined period of time. The LIAC is used when a device will be discoverable for only a limited period of time. Service Discovery Different Bluetooth devices offer different sets of services. Hence, a Bluetooth device needs to do a service discovery on a remote device in order to obtain information about available services. Service searches can be of a general nature by polling a device for all available services, but can also be narrowed down to find just a single service. The service discovery process uses the Service Discovery Protocol (SDP). An SDP client must issue SDP requests to a SDP server to retrieve information from the server's service records. Bluetooth devices keep information about their Bluetooth services in a Service Discovery DataBase (SDDB). The SDDB contains service record entries, where each service record contains attributes describing a particular service. Each service has its own entry in the SDDB. Remote devices can retrieve service records during service discovery and will then possess all information required to use the services described. Each attribute is assigned an attribute ID, being a hexadecimal identifier. Note that only two attributes are required to exist in a service record, the ServiceRecordHandle (attribute ID 0x0000) and the ServiceClassIDList (attribute ID 0x0001) attributes. Different attributes contain values of various types and sizes. To cope with this, data elements are used for storing values. A data element consists of a data element type descriptor and a data field. The data element type descriptor contains information about the type and size of the data and the data field contains the actual data. A remote device will then know what kind of data and how much data it is receiving when retrieving a service attribute. The Universally Unique IDentifier (UUID) is the data type used for identifying services, protocols and profiles etc. Profiles Bluetooth profiles provide a well defined set of higher layer procedures and uniform ways of using the lower layers of Bluetooth. The profiles guide developers on how to implement a given end-user functionality using the Bluetooth system. The profiles released with the Bluetooth specification version 1.1 are called foundation profiles. Using profiles ensure interoperability between different devices from different Original Equipment Manufacturers (OEMs). Consumers should be able to buy a cellphone from one vendor and a headset from another and have them working nicely together assuming that both devices implement the headset profile. Generic Access Profile (GAP): The basis for all profiles in the Bluetooth system. The GAP defines basic Bluetooth functionality like setting up L2CAP links, handling security modes and discoverable modes Serial Port Profile (SPP): Provides serial port (RS-232) emulation based on the RFCOMM part of the Bluetooth stack Dial Up Networking Profile(DUNP): Defines functionality for using a Bluetooth device as a Dial Up Networking gateway FAX Profile: Defines functionality for using a Bluetooth device as a FAX gateway Headset Profile: Defines the functionality required to do audio transfer with e.g. a wireless Bluetooth headset LAN Access Point Profile: Defines functionality for using a Bluetooth device as a LAN access point Generic Object Exchange Profile(GOEP): Provides support for the OBjext EXchange (OBEX) protocol over Bluetooth links Object Push Profile: Defines functionality for exchanging vCard and vCalendar objects, based on the GOEP File Transfer Profile: Defines functionality for navigating through folders and copying/deleting/creating a file or folder on a Bluetooth device, based on the GOEP Synchronization Profile: Defines functionality for synchronizing Object Stores containing IrMC objects (vCard, vCalendar, vMessaging and vNotes objects) between Bluetooth devices, based on the GOEP Intercom Profile: Enables Bluetooth devices to establish a direct communication link similar to intercom communcation The Cordless Telephony Profile: Enables Bluetooth devices to act as regular cordless phones communicating with e.g. an ISDN gateway Security Modes three security modes are defined, enforcing different levels of security. A security manager is used to handle the security transactions in the Bluetooth system. Security modes are part of the GAP profile. The OEM must decide which security mode to support when implementing the GAP. No security: devices will never initiate any security procedure Service level enforced security: used for the majority of Bluetooth devices. Security is enforced at the service level, hence the service decides whether security is required or not. Note that in service mode 2 security procedures are initiated by the higher Bluetooth layers after the Bluetooth link is created by the lower layers. Link level enforced security: security procedures are initiated during the setup of a Bluetooth link. If security measures fail, the link setup will fail. Application developers have no influence on the security settings when setting up a Bluetooth link. Security mode 3 is useful for Bluetooth devices which have factory preset settings and is not configurable by the user, e.g. Bluetooth headsets. Pairing and Bonding Bonding is the procedure of a Bluetooth device authenticating another Bluetooth device, and is dependent on a shared authentication key. If the devices do not share an authentication key, a new key must be created before the bonding process can complete. Generation of the authentication key is called pairing. The pairing process involves generation of an initialization key and an authentication key, followed by mutual authentication. The initialization key is based on user input, a random number and the Bluetooth address of one of the devices. The user input is referred to as a Personal Identification Number (PIN) or passkey and may be up to 128-bits long. The authentication key is based on random numbers and Bluetooth addresses from both devices. The initialization key is used for encryption when exchanging data to create the authentication key, and is thereafter discarded. When the pairing process is completed, the devices have authenticated each other. Both devices share the same authentication key, often called a combination key since both devices have contributed to the creation of the key. When two devices have completed the pairing process they may store the authentication key for future use. The devices are then paired and may authenticate each other through the bonding process without the use of a passkey. Devices will stay paired until one device requests a new pairing process, or the authentication key is deleted on either of the devices. Storing the authentication key is useful for devices frequently connecting to each other, such as a laptop computer frequently connecting to the dial-up networking service on a cellphone. The bonding procedure can then complete without user input and the user is relieved of figuring out a new passkey every time he or she wants to connect to the Internet. Encryption When two devices have authenticated each other encryption may be requested for the Bluetooth link by either of the devices. Before encryption can begin, the devices must negotiate encryption mode and key-size for the encryption key. When encryption has been requested and both devices support encryption, the size of the encryption key is negotiated. The master device will then suggest its largest supported key-length. The slave device may then accept or reject this key-length. If the slave accepts, all is well and encryption may be started. If the slave rejects, the master can suggest a shorter key-length or decide to terminate the connection. This procedure is repeated until the devices agree on a key-length or the master decides to terminate the link. Key-lengths from 8-128 bits are supported for encryption keys. This is due to export restrictions from the U.S. to some countries. There are three encryption modes: no encryption: The no encryption mode will only be selected if either of the devices do not support encryption. encrypt both point-to-point and broadcast packets only encrypt point-to-point packets: When only two devices are connected, the point-to-point packets encryption mode is a natural choice. Authorization Authorization is the process of giving a remote Bluetooth device permission to access a particular service. In order to be authorized the remote device must first be authenticated through the bonding process. Access may then be granted on a temporary or a permanent basis. The trust attribute is related to authorization, linking authorization permissions to a particular device. A trusted device may connect to a Bluetooth service, and the authorization process will complete successfully without user interaction. This means that the previously mentioned user with the laptop computer and cellphone may completely avoid user interaction with the cellphone when connecting to the Internet. By marking the laptop computer as a trusted device on the cellphone, the laptop computer may be authorized automatically when connecting to the dial-up networking service on the cellphone. Security Manager In order to keep track of which devices are trusted and the different levels of authorization for different services, security information needs to be stored in security databases. Two databases are used, one for devices and one for services. Several layers need access to these security databases. The security manager allows uniform access to the security databases for all layers and is responsible for entering and extracting information from the security databases. Hence, all exchange of information from the different layers and the security databases goes through the security manager. Applications and protocols must register with the security manager in order to use security features. Other important tasks handled by the security manager are to query the user for a passkey during the pairing process and query the user for an authorization response when a remote device tries to connect to a service that requires authorization. The security manager must also provide an user interface to configure security settings on the device.